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ABSTRACT 

The  exchange  of  Computer  Aided  Design  (CAD)  information  between  dissimilar  CAD  systems 
is  a  problem.  This  is  especially  true  for  transferring  electronics  CAD  information  such  as  multi-chip 
module  (MCM),  hybrid  microcircuit  assembly  (HMA),  and  printed  circuit  board  (PCB)  designs. 
Currently,  there  exists  several  neutral  data  formats  for  transferring  electronics  CAD  information. 
These  include  IGES,  EDIF,  and  DXF  formats.  All  these  formats  have  limitations  for  use  in 
exchanging  electronic  data.  In  an  attempt  to  overcome  these  limitations,  the  Navy’s  MicroCIM 
program  implemented  a  project  to  transfer  hybrid  microcircuit  design  information  between 
dissimilar  CAD  systems.  The  IGES  (Initial  Graphics  Exchange  Specification)  format  is  used  since 
it  is  well  established  within  the  CAD  industry.  The  goal  of  the  project  is  to  have  a  complete 
transfer  of  microelectronic  CAD  information,  using  IGES,  without  any  data  loss.  An  Application 
Protocol  (AP)  is  being  developed  to  specify  how  hybrid  microcircuit  CAD  information  will  be 
represented  by  IGES  entity  constructs.  The  AP  defines  which  IGES  data  items  are  appropriate  for 
describing  HMA  geometry,  connectivity,  and  processing  as  well  as  HMA  material  characteristics. 


INTRODUCTION 

There  exists  today  within  the  Microelectronics  industry  a  variety  of  established  ECAD  (Electronic 
Computer  Aided  Design)  systems.  These  systems  all  have  their  own  proprietary  formats  for 
representing  ECAD  information.  To  communicate  with  another  ECAD  system,  design  information 
must  be  converted  to  a  neutral  format.  The  data  is  then  transferred  to  the  other  system  which  in  turn 
translates  the  information  from  the  neutral  format  to  its  own  proprietary  format,  figure  1.  This 
process  is  executed  everyday  within  an  engineering  company,  a  company’s  engineering  department, 
between  a  design  organization  and  a  manufacturing  organization,  and  between  a  customer  and  a 
fabricator.  Unfortunately,  this  process  is  not  robust,  numerous  errors  occur  during  the  translation 
portion  of  the  processes.  Errors  are  often  in  the  category  of  missing,  incomplete,  or  extraneous 
information,  see  Table  1.  As  a  result,  the  design  file  received  into  the  receiving  CAD  system  must 
often  be  edited  or  updated.  The  update  process  consist  of  returning  the  file  into  a  robust  state.  The 
goal  is  to  have  the  transferred  file  be  equal  (functionally  and  informationally)  to  the  original  file. 
This  can  often  be  a  .very  tedious,  expensive  and  time  consuming  process  for  larger  CAD  files 
depending  upon  the  extent  of  repair  to  be  done. 


Table  1 

Typical  Transfer  Problems  Using  IGES 
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1.  Loss  of  information  on  different  layers. 

2.  Loss  of  dimensional  intelligence. 

3.  Alteration  of  text  and  line  fonts, 

4.  Loss  of  non -geographical  information. 

5.  Loss  of  connectivity  information 

6.  Loss  of  components  configuration  info. 

7.  Loss  of  routing  information. 
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The  U.S.  Navy  must  often  bear  the  final  cost  of  the  problems  its  manufacturers/suppliers  have 
in  transferring  CAD  information.  For  this  reason,  the  U.S.  Navy,  through  its  MicroCIM  project  office 
at  NCCOSC  RDT  «fe  E  Division,  decided  to  investigate  this  problem.  The  MicroCIM  program  was 
charged  with  working  with  the  military  hybrid  microcircuit  assembly  (HMA)  industry  to 
implement/develop  new  technology.  One  such  technology  is  the  errorless  transfer  of  hybrid 
microcircuit  ECAD  information  between  dissimilar  CAD  systems.  A  method  for  achieving  this 
exchange  using  an  established  neutral  format  has  been  developed.  The  neutral  format  chosen  is  IGES 
(Initial  Graphic  Exchange  Specification)  for  reasons  which  will  be  discussed  later.  The  method  was 
put  in  the  form  of  an  Application  Protocol  (AP),  so  called  because  the  method  is  a  protocol  for 
applying  IGES  in  the  successful  transfer  of  CAD  information.  The  AP  is  intended  to  be  used  by 
manufacturers  of  ECAD  systems  and  software  when  building  their  next  generation  systems[i].  The 
AP  details  to  the  manufacturer  how  to  represent  hybrid  design  constructs  in  the  IGES  format.  It 
standardizes  the  IGES  representation  of  a  hybrid  microcircuit  assembly  CAD  file.  This  standardized 
method  of  representing  HMA  design  file  entities  will  allow  the  errorless  transfer  of  HMA  ECAD  files. 
Referring  to  Table  1  it  is  seen  that  the  majority  of  errors  are  rooted  in  the  lack  of  standardization  in 
the  representation  of  HMA  ECAD  file  constructs  when  using  neutral  formats. 

The  remainder  of  this  paper  will  present  some  background  information  and  then  explain  the  AP, 
how  it  was  developed,  and  how  it  can  be  used. 

BACKGROUND 

HMAs 

The  focus  of  the  AP  is  on  the  electronic  information  necessary  to  fully  represent  hybrid 
microcircuit  assemblies.  Generally,  HMAs  are  non-monolithic  integrated  circuits,  made  up  of  two 
or  more  different  technologies,  and  may  consist  of  semiconductor  chips  and  capacitors  attached  to 
a  ceramic  substrate  with  printed  resistors  and  interconnections{i].  This  is  the  basic  definition  which 
is  used  in  the  AP.  This  definition  is  meant  to  be  inclusive  of  Multi-chip  Modules,  thick  film  HMAs, 
thin  film  HMAs,  and  low  temperature  co-fired  ceramic  (LTCC)  HMAs. 

IQES 

As  stated  earlier,  IGES  is  a  neutral  format  specification  for  describing  electronic  information  such 
as  CAD  files.  IGES  is  an  acronym  for  Initial  Graphics  Exchange  Specification.  It  is  a  specification 
which  had  it  first  release  in  the  early  80s.  The  purpose  of  the  standard  is  to  provide  a  means  by 
which  to  represent  and  communicate  product  definition  data  in  a  digital  format.  IGES  has  grown  to 
be  inclusive  of  almost  all  types  of  production  definition  data,  especially  CAD/CAM  information. 
This  data  can  be  in  the  form  of  engineering  drawings,  documentation,  2D  &  3D  designs,  and  solid 
models. 

In  the  ECAD  world  there  are  several  existing  neutral  file  specifications  for  various  areas  of 
electronic  information[l].  Two  such  specifications  used  in  the  analysis  and  hardware  areas 
respectively  are  EDIF  (Electronic  Design  Interchange  Format)  and  VHDL  (VHSIC  Hardware  Design 
Language).  IGES  was  chosen  over  EDIF  and  VHDL  for  implementation  in  the  AP  f or  several  reasons; 
l)It  is  a  standard  format  available  in  the  majority  of  CAD  systems,  ECAD,  drafting,  or  other,  2)It 
is  widely  used  in  industries  for  transferring  design  file  between  machines,  3)1GES  is  a  very  flexible 
Gnouage  with  multiple  ways  to  define  entities,  and  4)It  can  readily  represent  information  within  the 
scope  of  the  AP. 

To  put  ECAD  information  into  an  IGES  format  a  translator  is  required.  The  translator  operates 
by  mapping  information  contained  in  a  proprietary  ECAD  database  into  the  IGES  format[2].  The 
mapping  can  be  in  either  binary  or  ASCII  where  the  ASCII  generates  a  readable  IGES  file.  The  IGES 
file  structure  contains  five  distinct  sections.  The  Start  Section  contains  72  columns  of  human  read,ib!e 
comments  which  are  nc^  processed  by  the  progiam.  The  seeuud  section  is  the  Global  Section  which 
is  a  f ree  format  area  specifying  the  information  needed  by  the  pre-processor  and  information  needed 
by  post  processor  to  manage  a  file.  The  Directory  Entry  (DE)  section  and  Parameter  Data  (PD) 
sections  are  usually  the  largest  sections  in  the  IGES  file.  The  DE  section  contains  the  descriptive 
attribute  data  for  each  entity  used  in  the  original  file.  The  Parameter  Data  (PD)  section  follows,  and 


it  contains  entity  definition  and  actual  parameters  for  each  of  the  entities  in  the  DE  section.  The  Iasi 
section  in  an  IGES  file  is  the  terminate  section  which  contains  a  single  record  that  has  the  count  of 
the  records  in  each  previous  section.  The  IGES  version  5.0  manual  has  more  detailed  information 
about  this  as  well  as  detailed  information  on  current  entities  supported  by  IGES. 

APPLICATION  PROTOCOL  (AP) 

An  AP,  in  its  most  generic  form,  is  a  protocol  for  applying  some  type  of  information  or 
technology(  1  ].  In  our  case,  we  describe  how  to  apply  the  IGES  neutral  data  format  for  representing 
HMA  ECAD  information.  This  AP  develops  a  standard  representation  for  HMAs  so  as  to  minimize 
cost,  maximize  efficiency  in  the  design  process,  and  provide  a  means  for  handling  the  increasing 
complexity  of  HMAst2].  The  procedure  used  in  this  AP  (and  similar  APs)  involves  identifying  the 
information  required  to  fully  describe  an  application  area  (HMAs)  and  representing  that  information 
in  the  form  of  a  conceptual  model.  This  model  is  then  used  to  select  the  appropriate  IGES  constructs 
for  representing  the  information. 

Our  AP  is  centered  around  three  models:  AAM,  AIM,  ARM.  The  AAM,  Application  Activity 
Model,  presents  the  generic  activities  needed  to  design  and  fabricate  HMAs.  The  ARM,  Application 
Reference  Model,  represents  the  information  needed  to  support  the  AAM  activities  or  the  information 
generated  from  those  activities.  The  physical  location  of  the  information  contained  in  the  ARM  can 
be  found  in  the  AAM.  The  AIM,  Application  Interpreted  Model,  specifies  the  constructs  of  a 
standard,  such  as  IGES,  for  use  in  transferring  some  to  all  the  information  described  in  the  ARM. 
Together,  these  models  define  the  appropriateness  of  IGES  constructs  for  describing  the  geometry  of 
the  various  parts  of  a  hybrid  microcircuit,  its  inner  connectivity,  and  processing  and  material 
characteristics. 

The  scope  of  the  AP  is  to  support  design,  fabrication,  and  final  assembly  information  for  an 
HMA[1].  The  AP  does  not  support  all  information  required  for  electrical  testing  of  HMAs.  The 
information  contained  in  the  ARM  limits  the  AP  scope  to  layered  electrical  products  information 
which  is  currently  contained  in  ECAD  systems.  Other  sections  of  the  AP  describe  a)  definition  of  the 
terms  used  in  the  AAM,  ARM,  and  AIM,  b)  implementation  and  conformance  test  guide  lines,  and 
c)  AP  relationship  to  Units  of  Functionality. 

Modeling  Methodology 

The  AAM  and  ARM  were  developed  using  IDEF  methodology  in  order  to  represent  the 
information  being  conveyed  to  the  reader.  IDEF  was  developed  through  the  Air  Force’s  Integrated 
Computer  Aided  Manufacturing  Definition  Program.  The  AAM  is  built  using  IDEFO  which  is  an 
activity  modeling  method.  The  ARM  is  built  using  IDEFIX  modeling  method  which  is  an 
information  modeling  method.  The  AIM  modeling  method  was  created  specifically  for  this  AP  and 
is  based  upon  various  modeling  techniques.  The  component  parts  of  IDEFO  and  IDEFIX  models  are 
shown  in  figures  2a  and  2b  respectively,  IDEFO  models  are  composed  of  ICOMs,  arrows,  and  boxes. 
Each  activity  or  function  is  represented  by  a  box  which  takes  in  any  combination  of  Inputs,  Controls, 
Mechanisms,  and  Outputs  through  arrows.  Each  activity  can  be  decomposed  into  further  activities. 
An  entire  IDEFO  model  is  a  hierarchal  representation  of  a  process  composed  of  activities  and 
functions.  In  each  sub-level  are  the  activities  making  up  an  upper  level  function.  Arrows  pass 
information,  data,  and  product  between  levels  as  necessary. 

In  the  IDEFIX  method  a  piece  of  information  is  represented  as  an  entity,  a  relationship,  an 
attribute  to  an  entity,  or  some  type  of  assertion[3|.  The  IDEFIX  structure  is  top-down  where  top 
entities  (objects)  are  composed  of  bottom  entities.  Entities  are  represented  by  rectangles  as  shown 
in  figure  2b.  The  syntax  for  describing  relationships  between  entities  is  also  shown.  Entities  which 
are  beyond  the  scope  of  the  moHpl  have  a  dashed  rectangular  outline.  These  entities  are  in  the  model 
tn  complete  an  open  relationship  or  clarify  a  relationship. 

Application  Activity  Model 

An  organization  intending  to  implement  this  AP  would  look  at  the  AAM  to  see  if  their 
information  is  within  scope  and  within  the  context  needed  for  planning  the  necessary  automation 
changesll].  The  viewpoint  of  the  model  is  from  that  of  designers  and  manufacturers  of  hybrid 


microcircuit  assemblies.  The  model  is  meant  to  be  generic,  i.e.  it  is  not  specific  to  a  particular 
manufacturers  operations.  Unfortunately,  the  generality  of  the  model  leaves  many  open  issues.  For 
example,  the  model  as  it  stands,  applies  to  MCMs,  thick  film  hybrids,  thin  film  hybrids,  etc.  The 
fundamental  differences  between  these  technologies  is  not  represented  in  the  AAM.  The  other  AP 
models,  especially  the  ARM  has  facilities  for  differentiating  between  various  hybrid  technology  types. 
The  AAM  shows  where  the  information  in  the  ARM  is  used. 

Figure  3a  and  3b  show  model  diagrams  page  A-0  and  AO.  These  are  the  first  and  second  level 
diagrams  which  present  the  major  activities  necessary  to  produce  an  HMA.  The  A-0  shows  the  basic 
inputs,  controls,  and  mechanisms  required  to  produce  the  various  outputs  from  a  manufacture  hybrid 
devices  activity.  The  inputs  are  physical  things  such  as  Supplies  &  Materials  and  Industry  Technology 
as  well  as  information  from  Customer  Requirements.  Controls  on  the  activities  are  documentation 
like  military,  industry,  and  company  standards.  Controls  are  usually  those  things  which  are  not 
changed  in  any  form  by  the  activity  they  enter  into.  The  outputs  are  not  only  Shipped  Hybrids  but 
also  Scrap  generated  in  production  process.  Prototypes  built  before  production  and  required  to  be 
delivered  to  the  customer,  and  response  to  the  customers  request  for  price  quotes 

The  A-0  activity  is  decomposed  into  four  activities  which  are  the  core  of  an  HMA  manufacturer’s 
operations.  The  first  activity  is  the  Management  Of  Customer  Orders  which  uses  the  Customer 
Requirements  from  diagram  A-0  to  generate  a  Quote  Response.  The  second  activity  is  Performs 
Engineering  which  uses  Industry  Technology  and  Supplies  &  Materials  to  produce  Prototypes  in 
accordance  with  Standards  and  Customer  Requirements.  Data  generated  from  prototype  fabrication 
as  well  as  Scrap  Information  is  used  to  produce  various  engineering  documents.  This  activity  also 
produces  drawings,  schematics,  layouts,  released  design,  etc.  The  third  activity  Assure  Product 
Quality,  takes  in  drawings  and  other  documents  from  Perform  Engineering  and  Customer 
Requirements  information  to  produce  a  quality  plan.  Production  data  from  Produce  Hybrids  is 
analyzed  using  statistical  methods  and  results  are  fed  into  Produce  Hybrids  and  Perform  Engineering. 
The  final  activity  is  the  actual  production  of  hybrids.  Supplies  and  Materials  are  taken  in  and  the 
hybrids  along  with  documentation  are  produced  according  to  the  released  design  drawings  and  in 
keeping  with  standards.  Scrap  and  Production  data  are  also  generated.  The  remainder  of  the  AAM 
in  tht  AP  is  composed  of  decompositions  of  AO  activities  to  various  levels. 

The  AAM  was  arrived  at  by  consulting  previous  AAM  models  built  under  Navy  contract  by 
various  HMA  manufacturers.  Active  participants  in  the  building  of  the  AAM  were  the  Navy  and  two 
major  military  HMA  manufacturers.  Agreement  of  the  AAM  was  received  from  the  US  Navy’s 
MicroCIM  program  Ad-Hoc  Advisory  Panel,  a  group  composed  of  government,  industry,  and 
academia  interested  in  HMAs. 

Aoplication  Reference  Model 

The  ARM  describes  the  hybrid  product  information.  The  model  presents  an  enterprise-view  of 
information  of  the  hybrid  as  a  product(ll.  The  ARM  is  a  reference  point  for  implementation  of  the 
AIM.  It  shows  how  various  types  of  product  information  relate  to  one  another  and  how  a  particular 
piece  of  information  fits  into  the  concept  of  an  HMA.  The  documented  information  as  presented  in 
the  ARM  supports  the  activities  of  the  AAM.  It  also  provides  the  baseline  for  the  development  of 
the  AIM. 

Figure  4  presents  the  top  most  diagram  of  the  ARM  for  HMAs.  This  page  in  the  model  can  be 
read  as  follows  (refer  to  figure  2b): 

The  highest  level  entity  in  the  model  is  the  Hybrid  CAD  Presentation.  This  entity  has  one  key 
attribute.  The  key  attribute  uniquely  identifies  every  instance  of  the  entity.  The  other 
attributes  are  characteristics  of  a  Hybrid  CAD  Presentation  such  as;  layers  of  an  HMA  are 
built  on  separate  CAD  Layers.  The  connection  between  the  entities  Hybrid  CAD 
Presentation  and  Hybrid  Version  can  be  read:  Hybrid  CAD  Presentation  is  a  CAD  design  of 
zero,  one,  or  more  Hybrid  Versions.  A  Hybrid  Version  is  uniquely  identified  by  an 
attribute  called  Hybrid  ID.  The  Hybrid  Version  was  designed  using  zero,  one,  or  many 
Design  Rules  and  a  Design  Rule  is  involved  during  the  design  of  zero,  one,  or  many  Hybrid 
Versions.  The  dotted  line  between  these  two  entities  indicates  that  they  are  not  dependant 
upon  one  another.  A  Hybrid  Version  is  zero  or  one  Assembly  Occurrence  and  contains  zero. 


upon  one  another.  A  Hybrid  Version  is  zero  or  one  Assembly  Occurrence  and  contains  zero, 
one,  or  many  Assembly  Occurrences.  An  Assembly  Occurrence  is  uniquely  identified  by  an 
Assembly  Occurrence  ID,  it  also  has  an  attribute  representing  various  types.  An  Assemble 
Occurrence  is  dependant  upon  its  relationship  with  Hybrid  Version.  An  Assembly 
Occurrence  involves  zero,  one,  or  more  Process  Steps.  A  Process  Step  instance  is  uniquely 
identified  by  a  Process  Step  No.  and  has  Station,  Process  Description,  and  Log  Requirements 
as  attributes.  The  Process  Step  is  dependant  upon  the  relationship  it  has  with  Assembly 
Occurrence.  The  remaining  entity  to  entity  relationships  for  Process  Step  can  be  read  as 
follows.  A  Process  Step  is  produced  using  zero,  one,  or  many  Tools.  A  Process  Step  is  used 
in  one  or  more  Assembly  Consumables.  A  Process  Step  utilizes  zero,  one,  or  more  Patterns. 

A  Process  Step  is  followed  by  zero,  one,  or  many  Process  Steps.  A  Process  Step  has  attached 
zero,  one,  or  many  Hybrid  Assembly  Components.  A  Process  Step  achieves  an  assembly 
using  zero,  one,  or  more  Process  Operations.  The  entities  Hybrid  Assembly  Component, 
Pattern,  and  Process  Step  a.e  dependant  upon  their  relationship  with  Process  Step. 

The  remainder  of  the  diagram  can  be  read  as  above.  As  stated  previously,  the  ARM  is  the  baseline 
from  which  the  AIM  is  developed.  The  AIM  shows  how  the  information  contained  in  the  ARM  is 
to  be  expressed  by  subsets  of  IGES  entities. 


Application  Interpreted  Model 

The  scope  of  the  AIM  is  limited  to  LEP  (layered  electrical  products)  information  which  most 
ECAD  systems  contain.  HMAs  are  a  subset  of  the  wide  range  of  LEP  types  (ie.  MCMs,  Printed 
Circuit  Boards,  etc.).  The  IGES  entities  selected  for  implementation  in  the  AIM  were  selected  so  as 
to  minimize  the  total  file  size.  The  selected  IGES  entities  have  restrictions  placed  upon  their  use 
either  through  the  Global,  Direct  Entry,  or  Parameter  Data  sections.  This  is  done  so  as  to  restrict  the 
number  of  different  ways  a  particular  entity  is  used  within  an  HMA  CAD  file.  Other  IGES  entities 
can  be  used  within  a  file  but  they  should  not  be  used  for  purposes  stated  in  the  A1M[1].  Table  2  is 
a  subset  of  the  selected  IGES  entities.  The  Type  and  Form  headings  are  IGES  numbers  set  by  the 
standard  itself.  They  are  listed  so  that  an  implementer  of  the  AIM  can  refer  to  the  standard  for 
specific  information  on  the  entity.  The  Status  field  describes  the  entities  current  status.  Standard 
means  that  the  entity  exists  and  does  not  need  to  be  modified  to  be  used  in  the  AIM.  Gray  means  that 
the  entity  is  located  in  the  Gray  pages  of  the  current  IGES  version  document.  RFC  (Request  For 
Change)  means  that  the  entity  is  either  new  or  needs  to  be  modified  and  an  RFC  exists  and  is  in  the 
ballot  process.  New  means  that  the  entity  does  not  exist  and  an  RFC  needs  to  submitted.  Modified 
means  that  an  existing  entity  needs  to  modified  to  be  used  in  the  AIM.  The  AIM  individual  object 
definition  entity  models  contain  usage  restrictions  appropriate  to  the  application.  These  restrictions 
are  described  in  detail  in  the  AP  with  the  object  models.  Figures  5a  and  5b  are  two  sample  object 
models  from  the  AP. 


Table  2 

A  Sampling  of  IGES  Entities  used  in  AIM 


Status 

Type 

Form 

Standard 

100 

0 

Standard 

102 

0 

Standard 

106 

63 

Standard 

124 

0-1 

Modified 

125 

All 

Standard 

312 

1 

Modified 

402 

18 

New 

402 

5xxx 

Grey 

406 

27 

New ' 

406 

5xxx 

RFC 

406 

5xxx 

Description 
Circular  Arc 
Composite  Curve 
Copious  Data 
Transformation  Matrix 
Predefined  Planar  Shape 
Text  Display  Template 
Flow  Associativity 
Net  Connectivity  Assoc. 
Property-  Generic  Data 
Property-  Region  Fill 
Property-  Definition  Extent 


The  graphic  notation  developed  for  the  AIM  object  models  is  meant  to  ease  the  development 
of  unambiguous  translators  conforming  to  the  AIM.  The  notation  is  composed  of  several  principle 
elements;  Object  Definition  Block,  Object  Instance  Block,  Object  Value  Block,  and  Cardinality  code. 
The  latter  three  elements  are  related  and  derived  from  the  Object  Definition  Block.  Figure  6  is  the 
graphic  notation  for  the  Object  Definition  Block.  It  calls  out  an  IGES  entity  type,  form,  directory 
entry  value,  parameter  data  values,  and  relationships  to  other  IGES  entities.  Definitions  for  the  other 
graphic  notations  in  the  AIM  can  be  found  in  the  AP. 

For  readability,  the  diagrams  in  the  AIM  are  divided  into  six  subsections.  Section  one  contains 
the  AIM  interface  object  models.  These  represent  a  perspective  of  an  LEP  in  which  one  can  exchange 
data.  The  interface  object  models  describe  the  set  of  independent  entities  in  a  IGES  file  which  are 
part  of  an  LEP.  Currently,  there  exist  three  interface  objects  in  the  AIM;  Part  Library,  Physical 
Layout,  and  Technical  Illustration. 

Section  2  defines  objects  specific  to  LEPs.  Display  Geometry  is  section  3  and  defines  objects 
that  are  common  to  CAD/CAM  systems  that  use  2D  geometry.  A  miscellaneous  section  contains 
subordinate  objects  which  are  used  in  combination  to  form  an  LEP  specific  object.  There  is  also  a 
section  that  defines  objects  referenced  from  the  Direct  Entry  sections  of  other  objects.  In  the  final 
section  are  objects  that  represent  pre-defined  Direct  Entry  values.  Figure  5a  is  an  example  of  a 
model  from  the  Interface  Section,  figure  5b  comes  form  the  Display  Geometry  section. 

INDUSTRY  IMPLEMENTATION 

As  stated  in  the  introduction  it  will  be  up  to  private  industry  to  implement  the  AP.  Specifically 
it  is  expected  that  ECAD  system  manufacturers  such  as  Mentor  Graphics,  Intergraph,  Cadence, 
Harris,  and  Computer  Vision  will  implement  the  AIM  in  their  next  generation  of  translators  for 
ECAD  systems.  To  successfully  conform  to  the  AP,  these  vendors  must  design  their  ECAD  system 
translators  to  be  capable  of  reading  and  writing  CAD/CAM  files  that  conform  to  the  AIM.  The 
designers  and  manufacturers  of  HMAs  can  then  use  these  systems  without  having  to  worry  about  the 
cost  and  loss  in  efficiency  currently  inherent  when  transferring  CAD  files  between  dissimilar  ECAD 
systems  and  sometimes  between  the  same  type  of  system.  The  U.S.  Navy  ,by  building  this  AP,  has 
served  as  a  catalyst  for  a  solution  to  the  file  transfer  problem.  It  is  now  up  to  the  HMA  industry  to 
demand  the  implementation  of  this  solution  from  ECAD  system  manufacturers. 

FUTURE  DEVELOPMENT 

Conformance  requirements  and  testing  applications  have  not  yet  been  fully  developed  for  the 
AP.  It  is  hoped  that  industry  will  take  on  these  tasks  as  part  of  a  continuing  effort  to  improve  this 
Application  Protocol  for  hybrid  microcircuit  assemblies. 
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AAM  diagram  A-0,  top  of  model 
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Figure  4;  ARM  diagram,  top  of  model 
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Figure  5a:  Example  object  model  specific  to  Layered  Electrical  Products  (LEP) 
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Figure  5b:  Example  object  model  for  Display  Geometry 


